【セッションレポート】Developers.IO 2015 Treasure DataのAWS活用法 #cmdevio2015B
はじめに
Developers.IO 2015にスタッフとして参加しました。
trackBで行われた、「Treasure DataのAWS活用法」についてのレポートです。
セッション概要
Treasure Dataは、データの収集・蓄積・分析をクラウド上で提供するデータマネージメントサービスです。
現在はAWS/IDCF上でサービスを展開しているようです。
今回のセッションはTreasure DataのサービスがAWS上でどのようにスケーラブルなサービスを構築しているかお話をしていただきました。
スピーカーはトレジャーデータ株式会社の中川 真宏さんです。
内容について
Treasure Data System Overview
Treasure Data Systemの概要です。
・Job Queue
RDB上に作られている
・worker
データのインポートやクエリを担当する
HadoopやPrestoにクエリを投げる
Plazmaについて
Plazmaとはデータを保管/処理する仕組みです。
・Data import
50万レコードが毎秒インポートされている
430億レコードが1日にインポートされている
・Hive Query
1日に2兆レコードを読んでいる
1日3ペタほどのデータを処理している
・Presto Query
1日、1万クエリ以上処理している
AWSのコンポーネント
AWSのコンポーネントは下記を使用しています。
EC2
・Hadoop / Presto Clusters
・API Servers
S3
・MessagePack Columnar Storage
RDS
・MySQL for service information
・PostgreSQL for Plazma metadata
・Distributed Job Queue / Schedular
Cloud Watch
・Monitor AWS service metrics
ELB
・Endpoint for APIs
・Endpoint for Heroku
ElastiCache
・Store TD monitoring data
・Event de-duplication for mobile SDKs
EMRやSQSは使用していないようです。
EMRを使用しない理由として下記があります。
■マシンリソースとストレージを分けた
・データ量が増えているがクエリ量は増えていない
・データ量を増やすためにはノードを増やす必要がある
・リソースは余っている状態になるのでコストがもったいない
・クラウドを使用しているのでリソースを分けた
■HDFSは結構問題があるのでできればHDFSは使用したくない
・HDFSがクラッシュする
・HDFS clusterのアップデートが難しい
そのためS3を使用している
データインポーティングの話
Fluentdにデータをあげるが
レイテンシーやスループットの問題があるので
1レコードずつではなくファイルにしてある程度チャンクにまとめている
FluentdはチャンクにUnique IDを付与するので
Import Queueで重複検証をすることができる
Import QueueはMySQLを使用している
SQSにしない理由はSQSで初め作った時にデータを投げ続けると
重複が発生したのでSQSは使用しないことにした。
ImoprtwokerからPostgreSQLにデータを入れる
・Realtime Storage
→リアルタイム性
→時間をベースに
・Archive Storage
→S3を使用しているので小さいデータを入れるのは効率が良くないのでまとめてアップ
データプロセッシング
列ごとに保存、データ解析の鉄板
独自絡むストレージを作っている
column-based partitioning
time-based partitioning
codeだけ読んで解決できる
S3の問題 Eventual Consistency
1. Writing data / metadata first
> At this time, data is not visible
2. Check S3 data is available or not
> GET, GET, GET…
3. S3 data become visible
> Query includes imported data!
ネットワークコスト
・TDの場合
1000以上のコネクションをS3に貼っている
・recoverable error
→エラーをtdにためて自動でリトライ
・stall checker
進捗をチェックしてkill
リトライ処理
・S3のエラー
500
503
404
→リトライする
syntax error semantic error
exceeded task memory size
→リトライしない
Internal failureはリトライする
リトライ使うことで安定したデータが取れる
PostgreSQLの落とし穴
ミスマッチが起きる可能性がある
tcpのコネクションは切れるけど裏で動いている
そのためCloudWatchだけみてるとはまる
幾つかの拡張機能が使用されていない
結論
リソースとストレージは分ける
疎結合！
AWSはいくつか落とし穴があるけど避けることができる
たくさんのトレードオフがある
既存のコンポーネントを使用するか、新しいコンポーネントを使用するか
基本にこだわる！
まとめ
ビッグデータについて初めてのセッションに参加しましたが、AWSを使用しているエンジニアとしてはどのようにAWSを使用してデータを解析、保存、分析しているか詳しく説明されておりとても興味深いセッションでした。
またセッションの中で50万レコードが毎秒インポートされているとお話がありとても驚きました。
発表資料
[slideshare id=46410399&doc=developers-150329021913-conversion-gate01]
